Threat modeling has two distinct, but related, meanings in computer security. The first is a description of the security issues the designer cares about. This is the sense of the question, "What is the threat model for DNSSec?" In the second sense, a threat model is a description of a set of security aspects; that is, when looking at a piece of software (or any computer system), one can define a threat model by defining a set of possible attacks to consider. It is often useful to define many separate threat models for one computer system. Each model defines a narrow set of possible attacks to focus on. A threat model can help to assess the probability, the potential harm, the priority etc., of attacks, and thus help to minimize or eradicate the threats. More recently, threat modeling has become an integral part of Microsoft's SDL (Security Development Lifecycle) process.[1] The two senses derive from common military uses in the United States and the United Kingdom.
Threat modeling is based on the notion that any system or organization has assets of value worth protecting, these assets have certain vulnerabilities, internal or external threats exploit these vulnerabilities in order to cause damage to the assets, and appropriate security countermeasures exist that mitigate the threats.
Contents |
There are at least three general approaches to threat modeling:
Threat modeling has changed in recent times (around 2004) to take on a more defensive perspective rather than an adversarial perspective. The problem with an adversarial perspective is that it is reactive.
When you adopt an adversarial perspective, you examine software applications, or any system, by trying to find holes in it and ways they might be exploited. Techniques that are often used in an adversarial approach are penetration testing (white box and black box), and code review. While these are valuable techniques to discover potential problems, the flaw is that you can only use them once the software has been written.
This means that if you discover any security related problems, you have to rework and re-write your code. This is very expensive in terms of both time and money.
Security bugs have a much larger impact than functionality bugs. Since code around security usually touches every portion of the application, the 'ripple effect' makes the cost exponentially more expensive than functionality bugs.
Current threat modeling takes on a defender's perspective. This means that threats are examined and countermeasures, or security services, are identified at the design state of the application before any code is written. This way the defensive mechanisms are built into the code as it is written rather than patched in later. This is much more cost effective and has the added benefit of increasing security awareness in the development team. However, the disadvantage is that all threats can not be identified unless the code is trivially simple and often threat modeling on a defender's perspective will cause the development team to falsely believe that the code is secure.
A general high level overview of common steps in the defensive perspective threat modeling are: